home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / perfTuning / glprof.man < prev    next >
Text File  |  1994-08-01  |  28KB  |  570 lines
  1.  
  2. GLPROF(1)                                                            GLPROF(1)
  3.  
  4. NAME
  5.      glprof - profiling utility for IrisGL applications
  6.  
  7. SYNOPSIS
  8.      glprof [-n tracename] [ application ] [ -application_options ]
  9.  
  10. DESCRIPTION
  11.      glprof is an aid for profiling IrisGL applications.  Future versions of
  12.      glprof will support OpenGL applications as well.  glprof can be used to
  13.      understand the behavior and timing of visual simulation and animation
  14.      applications where the highest possible graphics performance and frame
  15.      rate are desired.
  16.  
  17.      glprof captures traces of the IrisGL commands that an application calls,
  18.      times the execution of these commands on a simulator, and displays the
  19.      results in graphical and textual form.  Optionally, object tags can be
  20.      inserted into the application's source code to aid in understanding the
  21.      profile display.  Host CPU times are also reported if the trace is
  22.      captured on a machine equipped with a free running hardware cycle
  23.      counter.
  24.  
  25. OPTIONS
  26.      -d database
  27.           Directory for traces.  Default is ./glf/
  28.  
  29.      -n tracename
  30.           Name for traces.  Default is the name of the application.
  31.  
  32. PROCEDURE
  33.      This is a general procedure to profile an IrisGL application:
  34.  
  35.    Insert object tags (optional)
  36.      glprof allows you to associate an object tag with each IrisGL command.
  37.      Each object tag is a hierarchical name composed of nonzero integer object
  38.      numbers, e.g. 17/32/69/91.  Object tags can be specified using the IrisGL
  39.      name stack commands initnames(), loadname(), pushname(), and popname().
  40.  
  41.      The name stack commands can be used either in immediate mode or in
  42.      display lists.  When an IrisGL application is not running under glprof,
  43.      these commands are used for picking and selection as usual and are
  44.      ignored outside of picking and selecting mode.  When an IrisGL
  45.      application is running under glprof these commands are executed as usual
  46.      by IrisGL, but they are also stored in the traces that are captured (even
  47.      when the application is not in picking or selecting mode).
  48.  
  49.      When a trace is profiled, glprof interprets the stored name stack
  50.      commands.  The object tag for each GL command in the trace is defined to
  51.      be the value of the name stack that is current when that command is
  52.      executed by the profiler.
  53.  
  54.                                                                         Page 1
  55.  
  56. GLPROF(1)                                                            GLPROF(1)
  57.  
  58.      You can use the command
  59.  
  60.      extern void glpObject(unsigned int inNum, const char *inName);
  61.  
  62.      in your IrisGL application to associate a string name with a nonzero
  63.      integer object number. This command is ignored when the application is
  64.      not running under glprof.  It is also ignored if inNum is zero.  It is
  65.      typically called during application initialization, but it may be called
  66.      at any time.  It is always executed immediately, even when IrisGL is in
  67.      display list mode.  It is legal to call glpObject() multiple times with
  68.      the same value of inNum.  When glpObject() is called, the association
  69.      between inNum and inName does not take effect until inNum is used in a
  70.      loadname() or pushname() command.  If string object names are specified,
  71.      the profile display will use them in place of integer object numbers.
  72.  
  73.      In previous releases of glprof, the command
  74.  
  75.      extern void glprof_object(const char *inName);
  76.  
  77.      could be used in IrisGL applications to insert object tags into traces.
  78.      For backward compatibility only, this command is still supported.  It has
  79.      been reimplemented using the new object tag scheme, as follows:
  80.  
  81.      void glprof_object(const char *inName) {
  82.          if (tracing && getopenobj() == -1) { /* no-op if display list mode */
  83.              glpObject(0x10000, inName);
  84.              trace_glLoadName(0x10000);
  85.          }
  86.      }
  87.  
  88.      Note that unlike previous implementations, the new implementation of
  89.      glprof_object does nothing if IrisGL is in display list mode.  If you
  90.      need to tag an object in a display list, simply call loadname(), and call
  91.      glpObject() during application initialization to associate a string with
  92.      the integer object number.
  93.  
  94.      In previous releases, glprof_object() was implemented in
  95.      /usr/lib/libglprof.a.  Since the implementation of glprof_object is now
  96.      built into glprof itself, /usr/lib/libglprof.a is no longer needed and is
  97.      not present in the current release.  Existing IrisGL executables that
  98.      were linked with -lglprof must be relinked without -lglprof in order to
  99.      use the new object tag scheme.
  100.  
  101.      In previous releases, the implementation of glprof_object() used the
  102.      IrisGL command charstr(), and as a result it was necessary to use the
  103.      IrisGL command cmov() before calling glprof_object() in order to prevent
  104.      object tags from appearing as character strings in the scene being
  105.      rendered.  This is no longer necessary.
  106.  
  107.    Run glprof
  108.  
  109.                                                                         Page 2
  110.  
  111. GLPROF(1)                                                            GLPROF(1)
  112.  
  113.      e.g.
  114.  
  115.      glprof myapp -f myarg1 -g myarg2
  116.  
  117.    Capture traces
  118.      Select the Capture button.  glprof runs the application under the control
  119.      of the trace capturer.  The application must be either a COFF executable
  120.      (IRIX 4.0.5 or earlier) linked with /usr/lib/libgl_s, an ELF executable
  121.      (IRIX 5.0 or later) linked with /usr/lib/libgl.so, or a shell script that
  122.      starts an ELF executable that is linked with /usr/lib/libgl.so.  When the
  123.      application is at the desired frame, move the mouse cursor into the
  124.      window to be traced and press the Pause key on the keyboard to capture a
  125.      single-frame trace.  Hold the key down until the mouse cursor turns into
  126.      an hourglass or until you hear a beep, then release the key.  You can
  127.      capture as many traces as you want.  When you are done, exit the
  128.      application normally.  For tracing to succeed, the application must be
  129.      continuously drawing frames and calling [m]swapbuffers() between frames
  130.      in the window that the mouse cursor is in while you are holding down the
  131.      Pause key.
  132.  
  133.    View the trace
  134.      Select a trace name in the trace list window with the left mouse button.
  135.      Press the View button.  The viewing window may be reshaped as desired.
  136.  
  137.    Select simulation options
  138.      Traces can be simulated on various hardware configurations.  Several
  139.      simulation parameters can be taken from the trace (Pass), or forced to
  140.      assume some other value for simulation timing purposes.
  141.  
  142.    Simulate and display profile results
  143.      Select the trace name and press the Profile button.  The profile display
  144.      window shows two bar graphs representing a simplified graphics pipeline,
  145.      with the upper one a magnified view of the lower one.  Bars report
  146.      activity of the Host CPU, Graphics Library, Transformation stage,
  147.      Clipping stage, Span generation stage, and pixel Fill stage.  With the
  148.      cursor below the mid-line, use the left mouse button to manipulate the
  149.      magnification left and right limits.  The upper bar graph also shows
  150.      object tag names and a bold line following the object into the graphics
  151.      pipeline.  Select an object with the left mouse button to obtain a
  152.      textual summary of the object.
  153.  
  154. DEFAULT SETTINGS
  155.      glprof reads the files ~/.glprofrc and ./.glprofrc to obtain default
  156.      settings for various parameters:
  157.  
  158.      # comments start with #
  159.      Prog = flight -D defs       # Default: ""
  160.      Trace = wingman             # Default: Prog[0] (e.g. "flight")
  161.      Comp = 1                    # Options: { 1,2,3,4 } Default: 1
  162.      Filter = MIP Pnt            # Options: { Point,Bilinear,MIP Pnt,MIP Lin,
  163.                                  #            MIP Biln,MIP Tri } Default: Point
  164.  
  165.                                                                         Page 3
  166.  
  167. GLPROF(1)                                                            GLPROF(1)
  168.  
  169.      Fog = Pass                  # Options: { Pass,On,Off } Default: Pass
  170.      Graphics = RE               # Options: { VGX,VGXT,RE } Default: RE
  171.      Host = Off                  # Options: { Pass,Off } Default: Off
  172.      Spans = 10                  # Options: { 5,10,20 } Default: 10
  173.      Texture = On                # Options: { Pass,On,Off } Default: Pass
  174.      Window = 100 x 200          # Default: Pass
  175.      Database = /usr/tmp/glf     # Default: ./glf
  176.      SharedThreshold = 1024      # Default: 4096
  177.      TraceKey = 162              # Default: 160 (PAUSEKEY; see <gl/device.h>)
  178.      TraceTextures = On          # Options: { On,Off } Default: On
  179.  
  180. FILES
  181.      ~/.glprofrc ./.glprofrc
  182.           default control settings.
  183.  
  184.       ./glf
  185.           default database location.
  186.  
  187.      /usr/sbin/glprof
  188.           the profiler.
  189.  
  190.      /usr/sbin/glprof_disp
  191.           the profile display program, forked by glprof.
  192.  
  193.      /usr/sbin/glprof_sim
  194.           the simulator, forked by glprof.
  195.  
  196.      /usr/sbin/glfcat
  197.           program that you can use to write traces to standard output in
  198.           human-editable text form.
  199.  
  200.      /usr/sbin/glftrace
  201.           program to capture traces, forked by glprof.
  202.  
  203.      /usr/sbin/glfview
  204.           program to view traces, forked by glprof.
  205.  
  206.      /usr/lib/libgltrace.so
  207.           run-time tracing library used by glftrace.
  208.  
  209.      /usr/lib/GLS/libGL.so
  210.           instrumented OpenGL library, used by glprof_sim.
  211.  
  212.      /usr/lib/GLS/libGLcore.so
  213.           instrumented OpenGL library, used by glprof_sim.
  214.  
  215.      /usr/lib/X11/dyDDX/glx.so
  216.           GLX extension to the X server (see BUGS, below)
  217.  
  218.                                                                         Page 4
  219.  
  220. GLPROF(1)                                                            GLPROF(1)
  221.  
  222. TRACE FILES
  223.      Each trace is stored as three files in the directory
  224.      <database>/<tracename>/.  The directory will be created if it does not
  225.      already exist.  Each file name begins with a decimal sequence number.
  226.      The file <num>.eglf is the header file, which contains references to the
  227.      other two files: the initialization file (<num>init.glf), which
  228.      establishes the GL state at the beginning of the traced frame, and the
  229.      scene file (<num>scene.glf), which contains the GL commands traced
  230.      between adjacent [m]swapbuffers() commands.  The header file is a human-
  231.      editable text file, while the other two are compact binary files.
  232.  
  233.      If your application uses fonts and/or textures, fonts and texture images
  234.      larger than a certain size threshold will be stored in separate binary
  235.      files called font<checksum>.glf and tex<checksum>.glf in the directory
  236.      <database>/SHARED/.  The initialization file of each trace will contain
  237.      references to these shared files, rather than including the fonts and
  238.      texture images directly.  This yields significant savings in disk space
  239.      when you capture many traces.  The default size threshold is 4096 bytes.
  240.      To set the size threshold to n bytes, put "SharedThreshold = n" in
  241.      ~/.glprofrc or ./.glprofrc.
  242.  
  243.      When you delete a trace that references one or more files in
  244.      <database>/SHARED, the referenced files will not be deleted.  To
  245.      eliminate all files in <database>/SHARED that are no longer referenced by
  246.      any trace, use the Scavenge Shared Files item in the Actions menu.
  247.  
  248.      If you don't have enough disk space to store traced texture images, put
  249.      "TraceTextures = Off" in ~/.glprofrc or ./.glprofrc.  This will force the
  250.      size of all traced texture images to be 1x1 pixels.
  251.  
  252.      The trace file format used by glprof in releases prior to IRIX 5.2 is no
  253.      longer supported.  Trace files in the old format cannot be interpreted by
  254.      glprof.
  255.  
  256.      Although the current release of glprof can only trace IrisGL applications
  257.      and not OpenGL applications, the trace file format is OpenGL-based.  The
  258.      trace capturer translates IrisGL commands to equivalent OpenGL commands.
  259.      Since it is impossible to perform this translation perfectly, some IrisGL
  260.      applications may not be traced properly.  In most cases, incorrect
  261.      translation will produces an erroneous visual effect in the viewer but
  262.      not affect the performance simulation done by the profiler.  In many
  263.      cases, a small change to the IrisGL application can solve the problem.
  264.      If your application is not traced properly, see the next section for more
  265.      details.
  266.  
  267.      The trace file format is still under development as a general purpose
  268.      OpenGL metafile mechanism.  SGI plans to support the metafile standard
  269.      that is eventually adopted by the OpenGL community.  It is likely that
  270.      the eventual standard will be at least somewhat different from the
  271.      current file format.  As a result, SGI does not guarantee that trace
  272.      files in the current format will be supported in future releases.
  273.  
  274.                                                                         Page 5
  275.  
  276. GLPROF(1)                                                            GLPROF(1)
  277.  
  278.      You can use the commands in the Edit menu to open a text editor on a
  279.      trace's header file, initialization file, or scene file.  Note that the
  280.      OpenGL commands in the header and initialization files are used only to
  281.      establish the correct initial GL state.  The profiler considers only the
  282.      OpenGL commands in the scene file.
  283.  
  284.      Since the trace file format is still under development and subject to
  285.      change, it is not documented in the current release.  The syntax is
  286.      similar to C source code.  The OpenGL API is defined in <GL/gl.h>.  You
  287.      may find it useful to edit trace files to make changes to OpenGL command
  288.      parameters (e.g., disable texturing in certain places) and then view and
  289.      profile the changed trace.  To comment out a line, insert a pound sign
  290.      (#) at the beginning of the line.  You can leave the viewer running as
  291.      you are editing the file; when you want to see the results of a change,
  292.      move the mouse cursor into the viewer window and type <Enter>.  This will
  293.      cause the viewer to reread the trace.
  294.  
  295.      If you edit an initialization file or scene file, glprof converts the
  296.      file from the default compact binary format to a human-editable format.
  297.      Since files are much larger and are processed much more slowly when they
  298.      are in the human-editable format, you may want to use the Recompress
  299.      command in the Edit menu when you are done editing.  This command
  300.      converts the initialization and scene files of the selected trace(s) back
  301.      to the compact binary format.
  302.  
  303. TRACE CAPTURER LIMITATIONS
  304.      The following paragraphs identify situations in which the IrisGL-to-
  305.      OpenGL translator in the trace capturer may fail.
  306.  
  307.      The translator ignores IrisGL commands and modes that have no equivalent
  308.      in OpenGL or the OpenGL GLU utility library.
  309.  
  310.      In the current release, the translator ignores several IrisGL commands
  311.      that do have equivalents in OpenGL or GLU:
  312.  
  313.          curveit()
  314.          lrectwrite()
  315.          rectcopy()
  316.          rectwrite()
  317.          writeRGB()
  318.          writepixels()
  319.  
  320.      Old-style IrisGL curve commands (crv(), crvn(),
  321.      patch(), rcrv(), rcrvn(), rpatch()) are
  322.      represented in traces as line segments connecting the curve control
  323.      points.
  324.  
  325.      If IrisGL object editing is done while a frame is being traced, the
  326.      editing commands and their effects will not appear in the trace.  The
  327.      edits will, however, affect subsequent traces.
  328.  
  329.                                                                         Page 6
  330.  
  331. GLPROF(1)                                                            GLPROF(1)
  332.  
  333.      If an mmode() command inside an IrisGL object changes the number of
  334.      IrisGL matrices (singlematrix/multimatrix) while a frame is being
  335.      traced, the appropriate commands to clear the OpenGL MODELVIEW matrix
  336.      stack will fail to appear in the trace.
  337.  
  338.      If the traced application relies on the fact that on some IrisGL
  339.      implementations the ModelView matrix is not applied when in
  340.      MPROJECTION mode, the translator will fail.
  341.  
  342.      If an IrisGL object contains an ortho(), ortho2(),
  343.      perspective(), or window() command, and if the number of
  344.      IrisGL matrices (singlematrix/multimatrix) is different when the
  345.      object is called from what it was at the beginning of the frame, the
  346.      translator will fail.
  347.  
  348.      The IrisGL pushattributes() command is traced as an OpenGL
  349.      glPushAttrib() command that saves a superset of the attributes
  350.      that should be saved:
  351.  
  352.          glPushAttrib(
  353.              GL_COLOR_BUFFER_BIT |
  354.              GL_CURRENT_BIT |
  355.              GL_ENABLE_BIT |
  356.              GL_LIGHTING_BIT |
  357.              GL_LINE_BIT |
  358.              GL_LIST_BIT |
  359.              GL_POLYGON_STIPPLE_BIT
  360.          );
  361.  
  362.      In other words, attributes are pushed in the OpenGL execution that
  363.      were not pushed in the IrisGL execution.  If the application changes
  364.      the value of these "extra" attributes and relies on the changed values
  365.      being preserved after an ensuing popattributes() command, the
  366.      translator will fail.
  367.  
  368.      While IrisGL has separate viewport and attribute stacks, in OpenGL
  369.      all attributes are pushed onto a single stack.  This can lead to
  370.      problems:
  371.  
  372.      pushattributes();   ->  glPushAttrib(ATTRIB_MASK);
  373.      pushviewport();     ->  glPushAttrib(VIEWPORT_MASK);
  374.      popattributes();    ->  glPopAttrib();
  375.      <commands>          ->  <commands>
  376.      popviewport();      ->  glPopAttrib();
  377.  
  378.      In this example, if <commands> relies on the attributes (and not the
  379.      viewport) being popped, the translator will fail.
  380.  
  381.      If the frontbuffer(), backbuffer(), leftbuffer(),
  382.      rightbuffer(), or zdraw() commands are used in an IrisGL
  383.      object, the translator may fail.
  384.  
  385.                                                                         Page 7
  386.  
  387. GLPROF(1)                                                            GLPROF(1)
  388.  
  389.      If lmbind() is called with a nonzero index inside an IrisGL object,
  390.      the translator will generate an OpenGL command to enable OpenGL lighting
  391.      if the target is either LMODEL or MATERIAL.  Since IrisGL enables lighting
  392.      only if both LMODEL and MATERIAL are bound to a nonzero index, lighting
  393.      might be enabled in the OpenGL execution at times when it shouldn't be.
  394.  
  395.      If texbind(TX_TEXTURE_0, i) or tevbind(TV_ENV0, i) is called with i != 0
  396.      inside an IrisGL object, the translator will generate an OpenGL command
  397.      to enable OpenGL texturing.  Since IrisGL enables texturing
  398.      only if both TX_TEXTURE_0 and TV_ENV0 are bound to a nonzero index,
  399.      texturing might be enabled in the OpenGL execution at times when it
  400.      shouldn't be.
  401.  
  402.      If the IrisGL color/normal flag is used to enable and disable lighting
  403.      within an IrisGL object, the translator may fail.
  404.  
  405.      If lmbind(MATERIAL, n) is used to enable or disable IrisGL lighting within
  406.      an IrisGL bgn/end pair, the translator will fail.
  407.  
  408.      If lmcolor() is used within an IrisGL bgn/end pair, the translator will
  409.      fail.
  410.  
  411.      If swaptmesh() is called inside an IrisGL object that does not also
  412.      directly contain all of the IrisGL commands from the preceding
  413.      bgntmesh() to the following endtmesh(), the translator will fail.
  414.  
  415.      If backface() and frontface() are both used, and if one or
  416.      both of these commands are called inside an IrisGL object, the
  417.      translator may fail.
  418.  
  419.      If the traced application uses concave polygons, the translator may
  420.      fail.
  421.  
  422.      If the traced application draws polygons with shademodel(FLAT),
  423.      the translator may produce a trace with incorrect colors.  The color
  424.      of each flatshaded polygon will be that of the first vertex (the
  425.      OpenGL convention), not the last vertex (the IrisGL convention).
  426.  
  427.      If the traced application uses depth cueing, the translator may
  428.      produce a trace with incorrect colors.
  429.  
  430.      If winset(), GLXwinset(), or [m]swapbuffers() is
  431.      called while IrisGL is in feedback, picking, or selecting mode, the
  432.      translator will fail.
  433.  
  434.      If [m]swapbuffers() is called while IrisGL is in object-creation
  435.      mode, the translator will fail.
  436.  
  437.      If the application loads textures using the TX_PIXMODE external format
  438.      or the commands subtexload() or fbsubtexload(), the
  439.      textures in the trace will be solid gray.
  440.  
  441.                                                                         Page 8
  442.  
  443. GLPROF(1)                                                            GLPROF(1)
  444.  
  445. NOTES
  446.      If your IrisGL application has errors that cause warnings when you run
  447.      the application under gldebug, the trace capturer may fail.  If you have
  448.      trouble capturing traces, use gldebug to check the correctness of your
  449.      application.
  450.  
  451.      Some IrisGL applications obtain input via a transparent X window covering
  452.      the GL rendering window.  This has the side effect of preventing IrisGL
  453.      from receiving keyboard button events.  To capture a trace from such a
  454.      program, you should use a .glprofrc file to set the TraceKey to the left,
  455.      middle, or right mouse button (101, 102, or 103, respectively, as defined
  456.      in <gl/device.h>).
  457.  
  458.      If your IrisGL application is single-buffered, you can capture traces
  459.      from it if you add a swapbuffers() command at the end of each frame.
  460.      This command will have no effect when you application is not running
  461.      under glprof.
  462.  
  463.      If you run a program under the trace capturer, and that program starts
  464.      other programs, those programs will also run under the trace capturer.
  465.      For example, if you run the demo shell program (/usr/demos/bin/buttonfly)
  466.      under the trace capturer, you can capture traces from any of the IrisGL
  467.      programs that buttonfly starts.  This rule does not apply to COFF (IRIX
  468.      4.0.5 or earlier) executables.  If the traced program tries to start an
  469.      OpenGL program, the OpenGL program will fail to run.
  470.  
  471.      The current release of glprof runs on any SGI graphics system and
  472.      supports the simulation of the following SGI graphics systems:  VGX,
  473.      VGXT, and RealityEngine.  If your target graphics system is not in this
  474.      set, glprof can still be a very useful tuning tool.  In particular, much
  475.      of the information in the the textual profile display is independent of
  476.      the particular graphics system being simulated.
  477.  
  478.      An application that uses display lists may run very slowly under the
  479.      trace capturer if the application is rendering to a remote display.  The
  480.      reason for this is that the trace capturer forces display lists to be
  481.      created on the machine that the application is running on, not the remote
  482.      machine.
  483.  
  484.      The program /usr/sbin/glfcat writes a trace to standard output in human-
  485.      editable text form.  Use the -h option to get a list of the available
  486.      options.  Use the -r (recursive) option to include the contents of
  487.      referenced files instead of just their names.  Since traces can be large,
  488.      you will probably want to pipe the output to a file, e.g.:
  489.  
  490.      glfcat -r flight/0.eglf > flight.eglf
  491.  
  492.      The viewer supports a small number of single-character keyboard commands.
  493.      Some of these commands cause the viewer to write text to its standard
  494.      output.  With the mouse in the viewer window, type h for a list of
  495.      commands.
  496.  
  497.                                                                         Page 9
  498.  
  499. GLPROF(1)                                                            GLPROF(1)
  500.  
  501.      Of particular interest is the viewer's timing loop command (t).  The
  502.      viewer measures the time to draw a frame using OpenGL, and the result
  503.      appears in the viewer window title.  The measured frame time should be
  504.      interpreted as a very loose upper bound on the time your application
  505.      would take to draw a frame using IrisGL if it spent no time between GL
  506.      calls.
  507.  
  508.      The measured frame time is a very loose upper bound for two reasons.
  509.      First, in the current release the viewer has not yet been tuned for
  510.      maximum OpenGL drawing performance.  Second, the translation from the
  511.      IrisGL commands generated by your application to the OpenGL commands
  512.      stored in traces is generally accurate enough for performance simulation
  513.      purposes, but in many cases the simple-minded automatic translation
  514.      produces significant inefficiencies in the OpenGL execution that do not
  515.      occur in the IrisGL execution (and would also not occur if you actually
  516.      ported your application to OpenGL).  For example, the IrisGL drawmode()
  517.      command is translated to an OpenGL command sequence that produces
  518.      visually correct results in the viewer but is quite slow.
  519.  
  520. BUGS
  521.      If OpenGL is not available on your system, glprof will still work, but
  522.      the View button will be grayed out and /usr/sbin/glfview will not work.
  523.  
  524.      If you install the optional gl_dev.sw.glprof software subsystem on a
  525.      system that does not support OpenGL, the X server will erroneously report
  526.      that it supports the GLX (OpenGL) extension to the X protocol, even
  527.      though it does not in fact support this extension.  This is due to the
  528.      presence of the file /usr/lib/X11/dyDDX/glx.so, which is necessary for
  529.      the proper functioning of glprof_sim.  If your system does not support
  530.      OpenGL, this file will be present only if you have installed
  531.      gl_dev.sw.glprof, and its presence will not cause your system to support
  532.      OpenGL.  If your system does not support OpenGL, and you install
  533.      gl_dev.sw.glprof while the system is running using the IRIX (not
  534.      miniroot) software installation technique, you must restart the X server
  535.      so that it will recognize the presence of /usr/lib/X11/dyDDX/glx.so.
  536.  
  537.      The Profile command will fail if the machine that is used to run glprof
  538.      does not have a local graphics display and an X server running, even if
  539.      the DISPLAY environment variable is used to place the glprof window on
  540.      another machine.  This restriction is due to limitations in the
  541.      implementation of glprof_sim.
  542.  
  543.      If the traced application uses IrisGL objects, the Capture command will
  544.      not work if the machine that is used to run glprof (and the traced
  545.      application) does not have a local graphics display, even if the DISPLAY
  546.      environment variable is used to place the glprof and application windows
  547.      on another machine.  This restriction is due to limitations in the
  548.      implementation of glftrace.
  549.  
  550.      The mechanism that glprof uses to measure host CPU times tends to
  551.      overestimate the time that your application spends between GL commands.
  552.      Unfortunately, there is no convenient way to determine how large this
  553.  
  554.                                                                        Page 10
  555.  
  556. GLPROF(1)                                                            GLPROF(1)
  557.  
  558.      error is.  If the measured host times seem excessive, use the "Host" menu
  559.      item to force the simulator to ignore host times.  More accurate results
  560.      for host time can be obtained with pixie(1) and prof(1).
  561.  
  562.      Not all IrisGL drawing commands and modes are simulated.
  563.  
  564.      In the current release, OpenGL applications cannot yet be traced.
  565.  
  566. SEE ALSO
  567.      gldebug(1), pixie(1), prof(1)
  568.  
  569.                                                                        Page 11
  570.